From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi@qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi@qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion@8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory@8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid@12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion@8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts@12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead@16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize@8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold@20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout@8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled@8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop@8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize@8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize@8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize@8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop@8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD@8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS@8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR@8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI@8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS@8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable@8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput@8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose@12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain@12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold@20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase@8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor@8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar@8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode@12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity@12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar@8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout@8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled@8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase@12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor@12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar@12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR@16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS@16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams@28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable@8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open@12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray@20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte@8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray@24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak@12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR@12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR@12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol@12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize@12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize@12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS@12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol@12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray@24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte@16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion@8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi@qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx@qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi@qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue Mar 14 23:22:06 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi@qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi@qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi@qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Tue Mar 14 23:22:06 2006 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:06 2006 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0001.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi@qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0001.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi@qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion@8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory@8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid@12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion@8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts@12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead@16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize@8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold@20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout@8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled@8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop@8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize@8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize@8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize@8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop@8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD@8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS@8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR@8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI@8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS@8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable@8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput@8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose@12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain@12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold@20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase@8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor@8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar@8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode@12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity@12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar@8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout@8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled@8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase@12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor@12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar@12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR@16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS@16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams@28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable@8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open@12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray@20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte@8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray@24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak@12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR@12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR@12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol@12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize@12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize@12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS@12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol@12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray@24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte@16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion@8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0001.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi@qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0001.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx@qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi@qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0001.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue Mar 28 18:25:31 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi@qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0001.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi@qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0001.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0001.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi@qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Tue Mar 28 18:25:31 2006 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:31 2006 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:31 2006 Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0002.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi@qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0002.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi@qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion@8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory@8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid@12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion@8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts@12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead@16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize@8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold@20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout@8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled@8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop@8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize@8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize@8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize@8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop@8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD@8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS@8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR@8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI@8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS@8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable@8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput@8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose@12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain@12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold@20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase@8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor@8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar@8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode@12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity@12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar@8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout@8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled@8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase@12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor@12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar@12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR@16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS@16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams@28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable@8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open@12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray@20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte@8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray@24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak@12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR@12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR@12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol@12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize@12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize@12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS@12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol@12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray@24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte@16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion@8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0002.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi@qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0002.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx@qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi@qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0002.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi@qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0002.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi@qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0002.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi@qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0002.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi@qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0003.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0003.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0003.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0003.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0003.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0003.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0003.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0003.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0004.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0004.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0004.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0004.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0004.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0004.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0004.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0004.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0005.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0005.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0005.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0005.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0005.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0005.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0005.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0005.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0006.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0006.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0006.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0006.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0006.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0006.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0006.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0006.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0007.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0007.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0007.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0007.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0007.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0007.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0007.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0007.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0008.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0008.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0008.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0008.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0008.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0008.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0008.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0008.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0009.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0009.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0009.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0009.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0009.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0009.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0009.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0009.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0010.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0010.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0010.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0010.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0010.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0010.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0010.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0010.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0011.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0011.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0011.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0011.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0011.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0011.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0011.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0011.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0012.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0012.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0012.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0012.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0012.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0012.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0012.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0012.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0013.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0013.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0013.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0013.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0013.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0013.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0013.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0013.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0014.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0014.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0014.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0014.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0014.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0014.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0014.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0014.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0015.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0015.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0015.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0015.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0015.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0015.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0015.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0015.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0016.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0016.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0016.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0016.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0016.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0016.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0016.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0016.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0017.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0017.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0017.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0017.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0017.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0017.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0017.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0017.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0018.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0018.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0018.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0018.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0018.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0018.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0018.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0018.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0019.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0019.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0019.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0019.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0019.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0019.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0019.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0019.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0020.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0020.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0020.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0020.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0020.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0020.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0020.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0020.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0021.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0021.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0021.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0021.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0021.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0021.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0021.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0021.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0022.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0022.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0022.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0022.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0022.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0022.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0022.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0022.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0023.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0023.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0023.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0023.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0023.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0023.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0023.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0023.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0024.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0024.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0024.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0024.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0024.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0024.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0024.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0024.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0025.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0025.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0025.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0025.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0025.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0025.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0025.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0025.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0026.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0026.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0026.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0026.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0026.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0026.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0026.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0026.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0027.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0027.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0027.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0027.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0027.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0027.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0027.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0027.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0028.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0028.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0028.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0028.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0028.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0028.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0028.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0028.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0029.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0029.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0029.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0029.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0029.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0029.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0029.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0029.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0030.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0030.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0030.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0030.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0030.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0030.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0030.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0030.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0031.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0031.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0031.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0031.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0031.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0031.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0031.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0031.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0032.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0032.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0032.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0032.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0032.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0032.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0032.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0032.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0033.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0033.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0033.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0033.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0033.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0033.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0033.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0033.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0034.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0034.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0034.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0034.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0034.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0034.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0034.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0034.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0035.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0035.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0035.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0035.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0035.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0035.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0035.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0035.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0036.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0036.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0036.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0036.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0036.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0036.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0036.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0036.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0037.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0037.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0037.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0037.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0037.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0037.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0037.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0037.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0038.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0038.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0038.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0038.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0038.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0038.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0038.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0038.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0039.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0039.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0039.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0039.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0039.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0039.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0039.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0039.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0040.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0040.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0040.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0040.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0040.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0040.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0040.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0040.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0041.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0041.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0041.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0041.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0041.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0041.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0041.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0041.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0042.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0042.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0042.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0042.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0042.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0042.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0042.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0042.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0043.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0043.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0043.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0043.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0043.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0043.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0043.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0043.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0044.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0044.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0044.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0044.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0044.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0044.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0044.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0044.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0045.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0045.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0045.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0045.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0045.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0045.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0045.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0045.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0046.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0046.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0046.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0046.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0046.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0046.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0046.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0046.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0047.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0047.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0047.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0047.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0047.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0047.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0047.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0047.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0048.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0048.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0048.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0048.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0048.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0048.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0048.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0048.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0049.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0049.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0049.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0049.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0049.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0049.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0049.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0049.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0050.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0050.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0050.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0050.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0050.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0050.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0050.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0050.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0051.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0051.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0051.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0051.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0051.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0051.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0051.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0051.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0052.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0052.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0052.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0052.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0052.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0052.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0052.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0052.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0053.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0053.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0053.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0053.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0053.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0053.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0053.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0053.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0054.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0054.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0054.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0054.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0054.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0054.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0054.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0054.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0055.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0055.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0055.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0055.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0055.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0055.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0055.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0055.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0056.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0056.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0056.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0056.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0056.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0056.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0056.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0056.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0057.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0057.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0057.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0057.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0057.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0057.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0057.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0057.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0058.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0058.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0058.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0058.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0058.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0058.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0058.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0058.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0059.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0059.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0059.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0059.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0059.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0059.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0059.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0059.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0060.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0060.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0060.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0060.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0060.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0060.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0060.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0060.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0061.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0061.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0061.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0061.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0061.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0061.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our